IBIS Macromodel Task Group Meeting date: 23 July 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: * Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: * Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Signal Edge Solutions * Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: Yifan: Prepare a draft of BIRD220.1 and send it to the ATM list. - Done. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the July 16th meeting. Michael moved to approve the minutes. Lance seconded the motion. There were no objections. -------------- New Discussion: BIRD220 update: Yifan reviewed a presentation on a work-in-progress update to the BIRD220.1 draft she had sent to ATM. The new version incorporated feedback received from Randy and others. BIRD220 introduced a [Pre-driver PSIJ Sensitivity] keyword with two sub-params providing single values for the rising and falling edges. BIRD220.1 proposes [PreDrv PSIJS Rising_edge] and [PreDrv PSIJS Falling_edge], both of which are tables in order to incorporate non-linearities. She reviewed the changes in the algorithm and the updated and simplified extraction process relative to BIRD220. One question received in response to the draft BIRD220.1 was whether we should scope the new keywords under the [Rising|Falling Waveform]s instead of [Model]. Yifan said we could discuss this possibility. However, she expressed concerns about this idea. She noted that rising and falling waveforms are generated under particular load conditions, and the model developer might not necessarily use the same load conditions when extracting the jitter sensitivity information. Arpad said that it is typical to extract 4 waveforms for an I/O buffer [Model] (2 rising and 2 falling), and he asked whether these PSIJ tables would be the same under all load conditions or need to be different for different waveforms. Yifan said the pre-driver sensitivity information should be identical for different load conditions, and the various loads are connected to the final driver and therefore would not affect the pre-driver behavior. Fangyi agreed and said the pre-driver sensitivity tables can't be dependent upon the load conditions, otherwise this whole approach doesn't work. Kinger said he thought the rising and falling waveforms in IBIS are for the final stage. He said they wouldn't care about the pre-driver stage. Arpad agreed that the rising and falling waveforms are largely about characterizing the output stage, but he noted that the way the driver turns on depends upon the way the pre-driver changes the gate voltage on the output transistor. So, there are pre-driver effects included. Randy noted that several years ago he had presented some data in ATM for a DDR5 device. He recalled that if you try to characterize PSIJ to different test loads, the data shifts around. He said we're trying to characterize the pre- driver delay and how it might be changing. If you don't have access to the pre- driver delay waveform, for example by probing at the gate of the driver, then you have to try and infer it from measurements of the final driver delay. That is where it can get messy. You could show what PSIJ is for four different waveforms and then try to infer what the pre-driver is doing. But ideally you want to characterize the pre-driver waveform itself. Arpad asked whether different values for V_fixture and R_fixture would affect the values in these new keywords. Randy said we could review his earlier data, but you'd have to try to infer what's going on in the pre-driver stage. Yifan drew a simple inverter chain pre-driver example connected to the output stage. She said the load is connected to the output stage, and the pre-driver delay won't change based on the output's load. So, we should only need a single table for the pre-driver portion (one each for rising and falling). Fangyi said this is expected behavior. The pre-driver ends at the gate. The gate voltage is decoupled from the load. Arpad said it's decoupled to some extent, but we do have the Miller capacitance between the drain and the gate. Randy observed that IBIS has always tried to provide data that could have been measured. He said this is an example of something you can't really measure. He said this is more like an AMI black box concept where you're providing data about something that's going on inside the device. This is great for a simulation-based model, but it's tough to come up with a measurement-based extraction. Arpad said we typically have 4 waveforms in order to characterize how the pre- driver turns the pullup and pulldown transistors on or off. He said this proposal contains separate tables for rising and falling, but he asked the group to consider whether we might need two tables for rising and two tables for falling. He noted that the rising waveform when you have a load of 50 Ohms to ground is governed by the pullup turning on. However, the rising waveform when you have 50 Ohms to Vcc is governed by the pulldown turning off. He said these were two different things, and if the pre-driver delay data would be different for these two conditions, then it would make sense to put that data under the rising and falling waveform keywords. Fangyi said that if we could do that, then we could account for all the jitter happening in the pre-driver and the driver. Then we could model what Randy observed. He said it would be a superset of this proposal, and we would have to go back and review the equations and figure out how to calculate a delay value at a certain load condition. He said that in a normal simulation scenario the model is not going to know the instantaneous load condition. We would have to rethink the formulation. Kinger said the pre-driver might well be operating at a different voltage than the final stage. So, we should not put pre-driver jitter sensitivity data inside the waveform data for the final stage. Yifan agreed and said it is noted as a limitation of this proposal that the pre-driver and final stage must share the same power net. Arpad agreed that IBIS itself currently doesn't support independent supplies for pre-driver and output stages. He said it's currently a fundamental limitation of IBIS. Yifan said we would need a different BIRD if we wanted to introduce support for different power nets for the pre-driver and final stages. Randy said that would also affect ISSO tables and other model keywords. Yifan proposed a case study with the load conditions for the 4 rising/falling waveforms to see if the pre-driver jitter sensitivity data is affected by load or not. Yifan noted another suggestion from Randy. Randy had suggested that we might allow the model maker to provide the jitter curve directly. The tool can then compute the derivative (jitter sensitivity in s/V) instead of asking the model maker to provide jitter sensitivity in the table. The keywords would be renamed to remove the "sensitivity". Yifan also noted that although the derivation of the jitter sensitivity is done with DC voltage values, it is applicable to AC power noise as well. Yifan said concern had been raised about the possibility of the time averaged VCC noise and the jitter sensitivity value resulting in a negative time shift delta t in the formulation: Ku(t) = Kuo(t + delta t) She said a positive or negative time shift is not a problem as the reference Ku0(t) curve has data at "all times". Fangyi agreed, he said this is not a true "time", it's a fictitious time that is more of a parameter of the K(t) table. Fangyi also noted that in the function representing the propagation delay (delta t), we should make it clear that "DC Jitter Sensitivity" is now a look up table value and not a constant. Yifan said she would send out a new BIRD220.1_draft2. She said she would perform the case study to determine whether pre-driver jitter sensitivity is affected by output load. [Ramp] and Ts4file: Michael shared a presentation detailing a possible ambiguity in the treatment of Ts4file, particularly by the ibischk parser. He reviewed the Ts4file Tx and Rx analog circuits (Figures 46 and 47, IBIS 7.2). He said that Arpad had explained that the Tx_R valued resistors are there to reduce reflections from the ideal stimulus sent to ports 1 and 3 of the Ts4file. Randy said Tx_R could represent the linearized drive impedance. The model maker could separate that from the .s4p file, or they could include that in the .s4p and set Tx_R to zero. Fangyi agreed that the model maker can include what they want in the Ts4file, and Tx_R is there to give the model maker flexibility. Fangyi said that Tx_R and Rx_R were introduced because historically many people mistakenly thought that when they got an S-parameter file they should terminate it with the reference impedance. Explicitly introducing Tx_R and Rx_R made it clear what values the model maker wanted the tool to use. Michael said the problem is that the ideal stimulus to the Ts4file is not well understood with respect to [Ramp] and the I-V and V-t tables in the IBIS file. For example, does the dV/dt value in the [Ramp] correspond to the ideal stimulus to the .s4p or the output of the .s4p? Ambrish asked whether Michael was looking for clarification on how [Ramp] interacts with Ts4file. He said Ts4file is an alternative analog buffer model for AMI only. He noted the first sentence in 10.10, IBIS 7.2: This section discusses an alternative analog buffer modeling technique, specifically designed for AMI applications. Fangyi then noted the final paragraph in 10.10.2, IBIS 7.2: By definition, the placement of the Ts4file information within .ami files makes the Ts4file data exclusively limited to AMI applications. If the same electrical behavior is desired for non-AMI applications of the same IBIS model (the one referencing the Algorithmic Model) the model maker can optionally provide an equivalent description using the [External Model] keyword. However, the latter is not needed if the model is intended for AMI applications only. Ambrish said the Ts4file is explicitly intended to replace the contents of the traditional IBIS analog model ([Ramp], I/V curves, etc.), and the parser should not be checking those elements in a model containing a Ts4file. The same is true if [External Model] is used. Michael said that we had not given that guidance to the parser developer. He said that if the caution level checking is enabled in the parser, which he strongly recommended all model makers do, then the parser issues cautions about the [Ramp] data even in AMI models using Ts4file. He said if the intent is that the traditional analog model elements be ignored when Ts4file is used, then that solves his problem. We need to submit a parser BUG and have the parser stop checking analog elements. Ambrish said that should be the case when [External Model] is used as well. Michael said he wasn't sure if the parser was checking traditional analog keywords in that case too. Randy agreed that we can update the parser behavior. - Ambrish: Motion to adjourn. - Michael: Second. - Arpad: Thank you all for joining. New ARs: Yifan: Prepare draft2 of BIRD220.1 and send it to the ATM list. ------------- Next meeting: 30 July 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives